Many service organizations define and manage work using the concept of a “work container”. Generally, a work container is considered to include a set of atomic tasks to be executed in some order, along with a specification of the role/skill needed for each task, the estimated effort and due date. As the name suggests, an “atomic task” is generally understood to be a task that is difficult to statically partition further (at the work container specification level), and which should ideally be assigned to a single resource. Atomicity does not necessarily derive from the granularity of the task, but may also be related to the fact that the task may not be easily parallelizable (i.e., performed in parallel) and may require a certain context/understanding to be preserved throughout its duration.
Generally, in conventional arrangements, a planning engine will act to attempt to assign each atomic task to a resource, and will impart a schedule to the by way of developing an overall plan. When resource utilization is very high, the planner may well encounter situations where resources with the right skill/role might exist for a given task, but the individual available effort from each resource is not sufficient for the task to be completed by the due date. In such cases, a common practice is to try and schedule the task for the earliest possible finish, by assigning it to the resource who can complete it earlier than others, even if this goes past the due date. However, in many settings, such a slippage in the schedule will invite a penalty to the organization. Alternatively, the organization may end up rejecting a work container when some of the atomic tasks cannot be scheduled on time, and of course this is often not a desirable outcome as it can lead to a loss of revenue.